Hi,

I am (re-)reading the drafts before the meeting and I have few comments:


1. the high/low bit part in "2.  DANE TLSA record overview".

Please drop/rewrite the bit part since it will become confusing when we adopt 
draft-ietf-tls-oob-pubkey for DANE.

2. Section 3.5 on CNAMES

The recommendation to follow the CNAME chain and do hop-by-hop checks won't 
work with most used protocol - HTTPS.  Generally you expect an TLS certificate 
for "www.iamconnecting.to" and not for "server.provider.srv" as suggested by 
the draft.

Also checking for CNAME means that the DANE PKI client would have to 
(re-)implement whole follow-the-CNAME login instead of using simple 
getaddrinfo().

So I am not sure if this is a sensible default.

O.

On 16. 7. 2013, at 1:58, Wes Hardaker <[email protected]> wrote:

> 
> FYI:
> 
> 
> From: [email protected]
> Subject: New Version Notification for draft-dukhovni-dane-ops-01.txt
> Date: 16. července 2013 1:45:48 GMT+2
> To: Viktor Dukhovni <[email protected]>, Wes Hardaker 
> <[email protected]>, Wesley Hardaker <[email protected]>
> 
> 
> 
> A new version of I-D, draft-dukhovni-dane-ops-01.txt
> has been successfully submitted by Viktor Dukhovni and posted to the
> IETF repository.
> 
> Filename:      draft-dukhovni-dane-ops
> Revision:      01
> Title:                 DANE TLSA implementation and operational guidance
> Creation date:         2013-07-15
> Group:                 Individual Submission
> Number of pages: 18
> URL:             
> http://www.ietf.org/internet-drafts/draft-dukhovni-dane-ops-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-dukhovni-dane-ops
> Htmlized:        http://tools.ietf.org/html/draft-dukhovni-dane-ops-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-dukhovni-dane-ops-01
> 
> Abstract:
>   This memo provides operational guidance to server operators to help
>   ensure that clients will be able to authenticate a server's
>   certificate chain via published TLSA records.  Guidance is also
>   provided to clients for selecting reliable TLSA record parameters to
>   use for server authentication.  Finally, guidance is given to
>   protocol designers who wish to make use of TLSA records to secure
>   protocols using a TLS and TLSA combination.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> -- 
> Wes Hardaker
> Parsons
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane

--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email protected]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to