<html><head></head><body>Que tal Roque.<br>
DANE permite incluir solo un hash, con el campo "selector" en 1 o 2:<br>
<br>
<br>
; <<>> DiG 9.8.4-P2 <<>> _443._<a href="http://tcp.www.vulcano.cl">tcp.www.vulcano.cl</a> tlsa<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58145<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0<br>
<br>
;; QUESTION SECTION:<br>
;_443._<a href="http://tcp.www.vulcano.cl">tcp.www.vulcano.cl</a>. IN TLSA<br>
<br>
;; ANSWER SECTION:<br>
_443._<a href="http://tcp.www.vulcano.cl">tcp.www.vulcano.cl</a>. 60 IN TLSA 3 0 1 5F301AD10923161E74EC4951C052C97963FEBCCB093019618964D69C AF7B5B34<br>
<br>
;; Query time: 587 msec<br>
;; SERVER: <a href="http://71.252.219.43">71.252.219.43</a>#53(<a href="http://71.252.219.43">71.252.219.43</a>)<br>
;; WHEN: Tue Aug 20 07:56:29 2013<br>
;; MSG SIZE rcvd: 89<br>
<br>
<br>
Saludos,<br>
<br>
Hugo<br>
<br><br><div class="gmail_quote">"Roque Gagliano (rogaglia)" <rogaglia@cisco.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Antonio,<br /><br />Otra alternativa es que simplemente baje el hash de la clave por DNSSEC pero obtenga la clave en-línea por otro mecanismo. Así funciona DNSSEC+SSH y creo que es más light que DANE que está pensado para bajar todo un certificado.<br /><br />El RR sería el SSHFP.<br /><br />Algunos ejemplos:<br /><a href="http://tools.ietf.org/html/rfc4255">http://tools.ietf.org/html/rfc4255</a><br /><a href="https://spaces.internet2.edu/display/~benchoff@vt.edu/DNSSEC+and+SSH+Key+Fingerprints">https://spaces.internet2.edu/display/~benchoff@vt.edu/DNSSEC+and+SSH+Key+Fingerprints</a><br /><br />slds<br />r.<br /><br /><br />On Aug 8, 2013, at 4:51 PM, Hugo Salgado <hsalgado@nic.cl> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hola Antonio.<br />Me parece una excelente idea. Pero recomendaría ponerlo dentro del<br />trabajo de DANE. No conozco mucho de NTP
ni
Autokey, pero si se trata<br />de la publicación de una llave formateada al estilo X.690, y el<br />protocolo es TLS, entonces es justo lo que DANE permite hacer. En<br />ese caso, bastaría con un registro en el DNS del estilo<br /><br />_563._<a href="http://tcp.ntp.example.com">tcp.ntp.example.com</a> IN TLSA ( .... )<br /><br />De todas formas sería necesario un documento explicando los detalles<br />específicos de Autokey, al estilo de lo que se está haciendo con SMTP:<br /><br /><a href="https://tools.ietf.org/wg/dane/draft-ietf-dane-smtp">https://tools.ietf.org/wg/dane/draft-ietf-dane-smtp</a>/<br /><br />Cuenta conmigo si necesitas ayuda de texto o revisión.<br /><br />Saludos,<br /><br />Hugo<br /><br /><br />On 08/07/2013 09:00 PM, Antonio M. Moreiras wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Eu não tenho certeza sobre a utilidade, ou viabilidade, dessa proposta.<br />Mas p
ensei
em fazer isso há algum tempo, e gostaria que vocês comentassem.<br /><br />Alguns servidores NTP disponibilizam Autokey (RFC 5906). Resumidamente,<br />é uma tecnologia de segurança que pode ser usada opcionalmente pelos<br />clientes para garantir a autenticidade e integridade da informação<br />recebida dos servidores.<br /><br />Pessoalmente, acredito que configurar diversas fontes NTP é o suficiente<br />para garantir o funcionamento correto de um cliente, e inviabilizar um<br />possível ataque. Também acho que não há muita motivação para alguém<br />atacar a estrutura NTP, havendo outros alvos mais fáceis e<br />interessantes. No entanto, nem todos pensam assim, e há quem ache o<br />Autokey algo útil e desejável. Então, diversos servidores públicos<br />oferecem essa possibilidade, inclusive os servidores que o <a href="http://NIC.br">NIC.br</a><br />administra, no Brasil.<br /><br />Um dos passos para que o cliente configure a funcionalidade é que
ele<br
/>recupere, com garantia de autenticidade e integridade, um arquivo<br />público contendo uma chave DSA no formato PEM. Uma forma de se fazer<br />isso é colocar essa informação num sítio https.<br /><br />Ao invés de usar um sítio https, me parece que se poderia colocá-la no<br />DNS dos respectivos servidores e recuperá-la com garantia de<br />autenticidade e integridade usando o DNSSEC. Isso facilitaria,<br />potencialmente, a configuração automática do Autokey, desde que o<br />software cliente seja alterado. Talvez se possa usar o campo TXT no<br />formato especificado na RFC 1464 para armazenar a informação. Talvez<br />algum outro campo.<br /><br />Embora eu não seja um forte defensor do Autokey, em si, acredito que<br />facilitar a configuração do NTP, em qualquer aspecto, pode ser benéfico,<br />de forma geral, e facilitar sua adoção.<br /><br />Existem mais possibilidades de configuração do Autokey do que técnicas<br />de transição no IPv6 (
para
quem não entendeu a piada, são muitas, uma<br />quantidade exagerada e assustadora). Há muitas possibilidades de<br />definição de grupos seguros e esquemas de identificação. Não tenho muita<br />certeza se alguém além do David Mills entende todas essas diferentes<br />possibilidades. Eu certamente não as conheço totalmente. A proposta não<br />abrangeria todos os métodos. Apenas um subset, que escolhemos por<br />considerarmos operacionalmente mais prático para uso na Internet.<br /><br />Alguém por aqui acha que isso seria útil?<br /><br />[]s<br />Moreiras.<br /><hr /><br />Ietf-lac mailing list<br />Ietf-lac@lacnog.org<br />Cancelar suscripcion: ietf-lac-unsubscribe@lacnog.org</blockquote><br /><hr /><br />Ietf-lac mailing list<br />Ietf-lac@lacnog.org<br />Cancelar suscripcion: ietf-lac-unsubscribe@lacnog.org</blockquote><br /><br /></pre></blockquote></div><br>
--<br>
Escrito en un teclado virtual. Disculpe abreviaciones y errores.</body></html>